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DETAILED ACTION 
Preliminary Amendment 

Examiner notes receipt of Applicant's Preliminary Amendment dated 1 1/21/2007. As 
such, amended Claims 1-2 & 4-8 are pending, Claims 9-12 are new, and Claim 3 is cancelled. 



Specification Objections 

The disclosure is objected to because of the following informalities: 

1 . Examiner suggests that Applicant review his/her use of acronyms in the 

specification. For example, Applicant states "ACR" in line 10, page 5 without 
explanation until lines 5-6, page 9 indicating "Accounting Request". Further 
IETF (line 18, page 5) is not defined but assumed to stand for "Internet 
Engineering Task Force" and UMTS is not defined (line 8, page 6). Here 
Examiner notes that Applicant repeatedly states "network element NE" (line 10, 
page 6 & line 11, page 6 & line 4, page 7, etc.), voiding the purpose for using 
acronyms, while defining "network entity" also as "NE" (line 17, page 7). 
Examiner suggests the use of reference characters to the drawings as opposed to 
the use of acronyms. 

Appropriate correction is required. 
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Minor Claim Objections 

Claims 1 & 9-12 are objected to because of the following informalities: 

1 . As per Claim 1 , Examiner suggests that Applicant use numbers or letters with the 

"indications" (e.g. "(a) a credit (b) an amount. . .(c) a source. . .") for clarity. 

Further, Examiner suggests that Applicant omit "of the deposit" after "said 
source" in the requesting step because "deposit" and "credit" are already used in 
abundance. Lastly, "Diameter Protocol" lacks antecedent basis. 

2. As per Claims 9 & 1 1 , Applicant may wish to include "network element" in the 
body of the Claim. Applicant docs not refer back to the preamble. 

3. As per Claims 10 & 12, Applicant may wish to include "account server" in the 
body of the Claim. Applicant does not refer back to the preamble. 

Appropriate correction is required. 

Claim Rejections - 35 USC§112-f Paragraph 

The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

Claims 9-12 are rejected under 35 U.S.C. 1 12, first paragraph, as failing to comply with 
the written description requirement. The claim(s) contains subject matter which was not 
described in the specification in such a way as to reasonably convey to one skilled in the relevant 
art that the inventor(s), at the time the application was filed, had possession of the claimed 
invention. 
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As per Claims 9 & 1 1 , Applicant never discusses "an interaction unit" or a "requesting 
unit" nor explains an "interaction means for" or a "requesting means for" in his/her 
original disclosure. As such, Applicant should clarify the record if he/she wants to assert 
specific structure that would have been known to one of ordinary skill in the art, at the 
time of Applicant's invention. Otherwise, such new matter should be canceled. 
As per Claims 10 & 12 , Applicant never discusses "a receiving unit" or a "depositing 
unit" nor explains a "receiving means for" or a "depositing means for" in his/her original 
disclosure. As such, Applicant should clarify the record if he/she wants to assert specific 
structure that would have been known to one of ordinary skill in the art, at the time of 
Applicant's invention. Otherwise, such new matter should be canceled. 

Claim Rejections - 35 USC § 112-2 nd Paragraph 

The following is a quotation of the second paragraph of 35 U.S. C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

Claims 1, 2, 4-9 & 11 are rejected under 35 U.S.C. 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

As per Claim 1 , Applicant mixes the use of "credit" and "deposit". For instance, should 
Applicant be stating "a source of the credit" or "a source of the deposit" in the interacting 
step? Further, Applicant introduces the Diameter protocol after a requesting step 
"wherein said requesting... request message identifying the request as a request". 
Examiner is concerned with the language chosen and suggests the use of alternate terms 
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for "request" if different defined terms are intended, [e.g. Does "the request" refer to the 
Diameter request message? Does "a request" refer to the requesting?] Further, Examiner 
is unsure whether "an amount" refers to "an amount of credit" and "an account" refers to 
an account associated to said user terminal. In addition, Examiner suspects that "an 
associated account" should be "said" associated account. Lastly, Examiner suggests that 
Applicant state "a first attribute value pair" in view of later Claim 4. 
As per Claim 2 , the term "value-added" is a relative term which renders the claim 
indefinite. The term "value-added" is not defined by the claim, the specification does not 
provide a standard for ascertaining the requisite degree, and one of ordinary skill in the 
art would not be reasonably apprised of the scope of the invention. Here, Examiner notes 
that Applicant's specification does not support, what exactly, is value added, [see 
Applicant's Specification page 3, line 7 & page 7, line 2.] Something may be value- 
added for one person and not value-added for another. 

As per Claim 4 , Examiner suggests the use of "second attribute value pair" and "third 
attribute value pair" to avoid ambiguity in view of Claim 1 . Further, Examiner notes 
Applicant's mixing of "credit" and "deposit" as "amount of credit" has support in Claim 1 
and "amount of said deposit" does not. 

As per Claim 5 , Examiner suggests the use of "second attribute value pair" as noted 
above. 

As per Claim 6 , the term "successful" is a relative term which renders the claim 
indefinite. The term "successful" is not defined by the claim, the specification does not 
provide a standard for ascertaining the requisite degree, and one of ordinary skill in the 
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art would not be reasonably apprised of the scope of the invention. Here, Examiner notes 
that Applicant's specification does not support, what exactly, measures success, [see 
Applicant's Specification page 3, line 24 & page 5, line 9 & page 10, line 7 (e.g. request 
message a success?) ] Examiner questions how one of ordinary skill in the art would 
interpret it being a success. Did the message get sent successfully? Was the message 
valid? Was the transaction approved? Here, Applicant gives no express direction. 
As per Claim 7 , said Claim is rejected under the same reasoning as Claim 6 above. Here, 
Applicant states "an acknowledgement" which could be interpreted as a different 
acknowledgment from Claim 6 that has a different measure of success. Is this where the 
transaction is approved? Here Applicant gives not express direction, [see Applicant's 
Specification, page 3, line 28 & page 10, line 13. ] 

As per Claim 8 , considering a broadest reasonable interpretation, Examiner questions 
whether "the amount being deposited" is equal to the amount requested. Examiner did 
not find clarification of this in Applicant's specification. Further, "an account" should be 
"said account". 

As per Claim 9 & 1 1 , Examiner is concerned that Applicant does not define a "network 
element". Under a broadest reasonable interpretation, "software" and "people" are 
elements of a network and would render said Claims non-statutory subject matter. As 
such, Examiner suggests that Applicant clarify the record. For purposes of examination, 
Examiner will assume a network element is a "server" [page 7, line 4] or a computer 
system [page 7, line 24, "network element decides" (e.g. via a processor)]. 
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Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

Claims 1, 4, 6-12 are rejected under 35 U.S.C. 103(a) as being unpatentable over Hilt et 
al (5,465,206) in view of Tsuda (09/994,013) [Pub. No.: 2002/0065785]. 
As per Claim 1 , Hilt et al ('206) teaches the method as follows: 

interacting with a user terminal [Abstract, Hilt et al ('206) indicates that apparatus used can be 
"an ATM, [a] PC or [a] telephone keypad" etc.] subscribed to a communication network 
[Abstract, "payment network" & column 1, line 65, "bill pay service bureau"] , wherein said 
interacting yields an indication of at least whether a credit is to be deposited on an account [Abstract, 
"consumers receive bills from participating billers (paper/mail bills, e-mail notices, 
implied bills for automatic debts)". Here, Examiner notes that one of skill in the art 
would appreciate that a credit is to be deposited to the biller's account.] associated to said 
user terminal [Examiner notes that said bill pay system works via PC interaction and that 
"payment origination is usually done electronically" (column 2, lines 4-5 & see column 
2, line 15)], an amount of credit to be deposited, and a source of the deposit, [Hilt et al ('206) 
discloses using "biller data" (column 2, line 10) to ultimately "credit the amount [due] to 
the consumer's account with the biller. (e.g. biller's account)" (column 2, lines 13-15, 
parenthetical added). Here, Examiner notes that said service indicates the source of funds 
as the "consumer's bank account" (column 2, line 9) either encoded on the instrument 
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(column 2, line 1 1) or "included with the [electronic] transfer" (column 2, line 16).] 
requesting said source of the deposit to deposit said amount of credit on said account associated to said user 
terminal, [Examiner notes that said requesting is inherent since any account holder must 
"order" his or her bank or payment service to transfer funds. Regardless, Hilt et al ('206) 
discloses the practice of "pre-authorization" where "billers get[] pre-authorization from 
consumers to submit debit requests to consumer's bank or a service" (column 3, lines 27- 
29). As such, with pre-authorization, one owed (payee) can request "said amount of 
credit" automatically from "said source of deposit" (payor account) to a payee account. 
This known method avoids a period of waiting for said payor to authorize or order his 
bank to make payment.] 

However, Hilt et al ('206) does not specifically disclose: 

wherein said requesting is based on the DIAMETER protocol, Regardless, Hilt et al ('206) does 
teach "participants agreeing] to a set of protocols [for] data exchange and messaging [] 
as well as operating regulations" [column 10, lines 41-43]. In this vein, Applicant admits 
as known, that "DIAMETER is an AAA (Authentication, Authorization, and Accounting) 
protocol specified in IETF." [Applicant's Specification, page 5, lines 16-18]. 
Nevertheless, Tsuda ('013) teaches the use of AAA protocols in "a mobile 
communication system" for the transmission of an "authentication and accounting request 
for requesting a desired accounting service at al AAAH server". As such, it would have 
been obvious to one of ordinary skill in the art, at the time of Applicant's invention, to 
modify Hilt et al ('206) to include DIAMETER as the protocol of use for the accounting 
request (e.g. requesting an amount of credit to an account). One would have been 
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motivated to do so given that DIAMETER is a known protocol and Tsuda ('013) supports 
its use in particularly the accounting field. 

wherein said requesting comprises generating a DIAMETER request message identifying the request as a 

request for depositing an amount to an account, Regardless, Hilt et al ('206) does disclose a biller 
and the biller's bank (service provider) agreeing "on a data transfer protocol for 
transferring A/R (accounts receivable, i.e. money owed) data" [column 18, lines 66-67, 
(parenthetical added)]. As such, it would have been obvious to one of ordinary skill in 
the art, at the time of Applicant's invention, to modify Hilt et al ('206) to include a 
DIAMETER request message identified as a request for deposit of an amount to an 
account. See use of DIAMETER discussion above. One would have been motivated to 
do so given that a biller using a payment network would necessarily be required to 
provide information where a payment service needs to collect funds and what amount 
(e.g. accounts receivable). Said payment service would then logically utilize such 
information to send requests via such agreed upon protocols. 

wherein said generated DIAMETER request message further comprises an attribute value pair identifying 
the user terminal to an associated account of which the deposit is to be deposited. Regardless, Hilt et al 
('206) does disclose the use of a "unique biller reference number (BRN) [column 10, 
lines 47-48] and "pointers" [column 10, line 58] which identify[y]the biller to the 
payment network" [column 10, lines 47-49] and the "C-B account numbers" (customer's 
account number with the biller) [column 10, line59]. As such, it would have been 
obvious to one of ordinary skill in the art, at the time of Applicant's invention, to modify 
Hilt et al ('206) to include a DIAMETER request message with an attribute value pair for 
linking a terminal to the account for credit of funds. See use of DIAMETER discussion 
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above. One would have been motivated to do so because the use of actual account 
numbers would disclose personal information and the use of an alternate identifier, 
including an attribute value pair, pointers, or unique identification numbers would avoid 
this issue and be more secure, [see also column 2, line 10, "encoding the consumer's bank 
account number"]. 

As per Claim 4 , Hilt et al ('206), as modified, teaches the method of Claim 1 above. 
However, Hilt et al ('206) does not specifically disclose said generated DIAMETER request 
message further comprises: an attribute value pair identifying said source of the deposit; and an attribute 

value pair identifying the amount of said deposit. Regardless, Hilt et al ('206) does disclose the 
identification of data via "a bar code, or other mechanically or electronically readable 
form'" [column 1, lines 45-6]. In this vein, Hilt et al ('206) specifically notes this data to 
be "account number, amount due", [column 1, lines 40-41]. Further, Hilt et al ('206) 
teaches "encoding the consumer's bank account number" with "the biller and MICR data" 
[column 2, lines 10-11]. Here, Examiner notes that check amounts are commonly known 
to be encoded in a MICR line. As such, it would have been obvious to one of ordinary 
skill in the art, at the time of Applicant's invention, to modify Hilt et al ('206) to include 
an attributed value pair for identifying (a) the source of funds and (b) the amount of funds 
to be deposited. One would have been motivated to do so for security purposes and to 
avoid the disclosure of customer information, especially given the use of outside 
"operations for remittance processing" [column 1, line 35]. Further, such attribute value 
pairs would further "uniquely identify the consumer" in biller records, [column 3, line 
51] 
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As per Claim 6 , Hilt et al ('206), as modified, teaches the method of Claim 1 above. 
Further, Hilt et al ('206) teaches acknowledging, by said source, whether said request was successful 
or not. ["Bank C (consumer's bank) then submits an electronic transaction, a payment 
message, into a payment network directed to Bank B (biller's bank), (see column 10, 
lines 64-66). Here, Examiner notes that Bank C's sending of a payment message 
obligates it to make payment through the payment network to Bank B by debiting their 
consumer's account, (column 11, lines 10-14). Thus, said message is acknowledgment 
that adequate funds were available in consumer's account and said request is being 
successfully processed.]. 

As per Claim 7 , Hilt et al ('206), as modified, teaches the method of Claim 6 above. 
Further, Hilt et al ('206) teaches depositing said amount to said account associated to said user 
terminal upon receiving an acknowledgment indicating success, ["bank B receives a net position 
from the payment network and credits biller B's bank account" (column 11, line 14) 
logically using "BRNs and/or C-B account numbers" (column 10, lines 53-54).]. 
As per Claim 8 , Hilt et al ('206), as modified, teaches the method of Claim 7 above. 
Further, Hilt et al ('206) teaches informing said user terminal of the amount being deposited to an 
account associated to said user terminal, [see Abstract, "biller's bank... provides A/R data to 
biller" & column 4, lines 37-38, "account statement.... ('A/R') data file". Otherwise, 
biller would send an "('NSF') notice", column 4, line 40.]. 
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As per Clam 9 , Hilt et al ('206) teaches the apparatus as follows: 

Note: Examiner notes that Claims directed to an apparatus must be distinguished 
from the prior art in terms of structure rather than function, In re Danfy, 263 F.2d 
844, 847, 120 USPQ 582, 531 (CCPA 1959). As such, a claim containing a 
"recitation with respect to the manner in which a claimed apparatus is intended to 
be employed does not differentiate the claimed apparatus from a prior art 
apparatus" if the prior art apparatus teaches all the structural limitations of the 
claim. Ex parte Masham, 2 USPQ2d 1657 (BPAI 1987). 

an interaction unit ["means of data and message processing" (column 12, line 54, (e.g. 
Examiner interprets this as a computer processor, display, modem, etc. as known in the 
art) and "computer systems" (column 12, line 56)] configured to interact with a user terminal 
subscribed to a communication network, wherein said interaction unit is further configured to yield an 
indication of at least whether a credit is to be deposited on an account associated to said user terminal, an 
amount of credit to be deposited, and a source of the deposit; [Here, Examiner asserts that 
computers are inherently configured/programmed to perform the methods desired, such 
as these limitations as discussed in Claim 1 above.] 

a requesting unit [a payment network comprising "[bank] computer systems [connected] to 
computer systems at other banks through an [access point] device" (column 11, lines 3- 
4)] configured to request said source of the deposit to deposit said amount of credit on said account 
associated to said user terminal [Here, Examiner asserts that computers are inherently 
configured/programmed to perform the methods desired, such as this limitation as 
discussed in Claim 1 above.] 

However, Hilt et al ('206) does not specifically disclose: 
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wherein said request is based on the DIAMETER protocol, AND wherein said requesting unit is further 
configured to generate a DIAMETER request message identifying the request as a request for depositing an 
amount to an account, AND wherein said generated DIAMETER request message further comprises an 
attribute value pair identifying the user terminal to an associated account of which the deposit is to be 
deposited. Regardless, Examiner reiterates that Hilt et al ('206) teaches a system 
implementing "pre-agreed protocols" [column 12, lines 46-47]. Further, Applicant's 
admission of the known DIAMETER protocol in combination with the teachings of 
Tsuda ('013) for the use of AAA protocol in communication networks makes said 
limitations obvious for implementation by an apparatus under the logic as outlined in 
Claim 1 above. One would have been motivated to do so for efficiency and to avoid 
computational or number transfer errors. Lastly, Examiner asserts that computers are 
inherently configured/programmed to perform the methods desired, such as these 
limitations as discussed in Claim 1 above.] 
As per Claim 10 , Hilt et al ('206) teaches the apparatus as follows: 

a receiving unit configured to receive a request message from a network entity to deposit an amount of 
credit on an account associated to a user terminal subscribed to a communication network, [Hilt et al 
('206) discloses a bill pay system, with a "central computer" (e.g. network entity, server) 
that uses an "ATM network (e.g. ATM as the receiving unit) to obtain funds in the 
amount of the payment from the consumer's ATM-accessible bank account" (column 2, 
lines 51-54).] 

a depositing unit configured to deposit the amount of credit on the account associated to said user terminal. 
[Hilt et al ('206) discloses a bill pay system, with a "central computer" (e.g. network 
entity, server) that obtains funds "into an account of the system operator" (column 2, line 
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55) and then "pay[s] the biller" via "wire transfer, [or] debit network" (column 2, line 

56) . As such, it is inherent that the ultimate user's (biller' s) terminal contains a 
depositing unit.] 

However, Hilt et al ('206) does not specifically disclose: 

wherein said request message is based on the DIAMETER protocol, AND wherein said DIAMETER 
request message identifies the request as a request for depositing an amount to an account, AND wherein 
said received DIAMETER request message further comprises an attribute value pair identifying the user 
terminal to an associated account of which the deposit is to be deposited; Regardless, Examiner 
reiterates that Hilt et al ('206) teaches a system implementing "pre-agreed protocols" 
[column 12, lines 46-47]. Further, Applicant's admission of the known DIAMETER 
protocol in combination with the teachings of Tsuda ('013) for the use of AAA protocol 
in communication networks makes said limitations obvious for implementation by an 
apparatus under the logic as outlined in Claim 1 above. One would have been motivated 
to do so for efficiency and to avoid computational or number transfer errors. Lastly, 
Examiner asserts that computers are inherently configured/programmed to perform the 
methods desired, such as these limitations as discussed in Claim 1 above.] 
As per Claims 11 & 12 , Applicant invokes 35 U.S.C §1 12-6 th paragraph by (1) utilizing 
the phrase "means for", (2) modified by functional language, (3) without an indication of 
sufficient structure, materials or acts to achieve those functions. In this vein, Claims 1 1 
& 12 would ordinarily be construed to cover the corresponding structure, material, or acts 
disclosed in the specification and equivalents thereof. However, Applicant's 
specification does not describe any further structure, material or acts. As such, Examiner 
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will interpret all claim limitations as reading on any prior art means which is capable of 
performing the specified functions under a broadest reasonable interpretation. 
As such, Examiner rejects said Claims under the same logic and evidence of Claims 9 & 
10 respectively above. 

Claim 2 is rejected under 35 U.S.C. 103(a) as being unpatentable over Hilt et al 
(5,465,206) in view of Tsuda (09/994,013) [Pub. No.: 2002/0065785] and further in view of 
Tubinis (10/162,232) [Pub. No.: 2003/0014367]. 

As per Claim 2 , Hilt et al ('206), as modified, teaches the method of Claim 1 above. 
However, neither Hilt et al ('206) nor Tsuda ('013) specifically discloses said interacting is 
based on a value-added multimedia application run on a multimedia application server provided in said 
communication network. Nevertheless, Tubinis ('232) teaches "a subscriber of a 
communications network" with "capabilities of the application and application server 
providing the service" of "multimedia content including audio, video, data or any 
combination thereof and the charging for such service, [see Abstract]. As such, it would 
have been obvious to one of ordinary skill in the art, at the time of Applicant's invention, 
to modify Hilt et al ('206) and Tsuda('013) to include said interacting involving credits 
associated with multimedia applications. One would have been motivated to do so given 
that implementation would require "using a multimedia control protocol" which realizes 
"[r]eal-time [] charging" and updating of accounts, [see Abstract]. 
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Claim 5 is rejected under 35 U.S.C. 103(a) as being unpatentable over Hilt et al 
(5,465,206) in view of Tsuda (09/994,013) [Pub. No.: 2002/0065785] and further in view of 
Official Notice. 

As per Claim 5 , Hilt et al ('206), as modified, teaches the method of Claim 4 above. 
However, neither Hilt et al ('206) nor Tsuda ('013) specifically discloses the DIAMETER 
request message is routed to said source based on said attribute value pair identifying said source of the 
deposit. Regardless, Official Notice is taken that it is old and well-established that banks 
(as associated with bank accounts) have routing numbers often represented in MICR 
lines. In line with the discussion in Claim 4 above, it would have been obvious to one of 
ordinary skill in the art, at the time of Applicant's invention, to modify Hilt et al ('206) 
and Tsuda ('013) to include the routing of a request message via routing information 
associated with an attribute value pair which identifies the source of a deposit. One 
would have been motivated to do so because a routing number is the means for a service 
provider to direct payments requests (e.g. presentments) to the right institution. Further, 
Hilt et al ('206) supports entities maintaining a "look up table for consumers]", which 
logically, will associate an attribute value pair to consumer information (e.g. account 
number at bank) and bank information (e.g. name, proper routing number). Accurate 
presentment is necessary for any funds transfer to take place. 
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Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to John D. Scarito whose telephone number is (571) 270-3448. The 
examiner can normally be reached on M-Th (7:30-5:00), Alternate F (7:30-4:00). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kambiz Abdi can be reached on (571) 272-6702. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/John D. Scarito/ John D. Scarito 

Examiner, Art Unit 3692 Examiner 



/Harish T Dass/ 

Primary Examiner, Art Unit 3692 



